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AMENDMENTS TO THE DRAWINGS 

Replacement sheets 1/12, 2/12/ 8/12 for Figures 1, 2 and 7 respectively are 
attached ~ together with sheets marked to show the changes in sheet numbering. 
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REMARKS/ARGUMENTS 

Reconsideration of this application is respectfully requested. 

The re-numbering of drawing sheets for Figures 1, 2 and 7 has been effected as 
requested and the specification has been amended as also requested. 

Accordingly, all outstanding formal issues are now believed to have been resolved 
in the applicant's favor. 

The rejection of claims 1, 2, 6, 7 and 11 under 35 U.S.C. §103 as allegedly being 
made "obvious" based on Muller in view of Epps is respectfully traversed — as is the 
rejection of claims 3, 4, 5, 8-10 and 12 under 35 U.S.C. §103 as allegedly being made 
"obvious" based on Muller/Epps in further view of Ambe. 

The Examiner is thanked for pointing out a possible confusion between the various 
Muller references. However, since the Muller patents all appear to describe basically the 
same architecture, this really should not effect the outcome. 

Claims 1, 2, 6 and 7 have been deleted. Claim 3 has been amended to include 
limitations taken from its base claim (claim 1). Claim 8 has also been amended to 
include limitations taken from its base claim (claim 6). Claim 1 1 has been amended to 
refer to the modification of a provisional port bitmask. 
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The applicant's invention concerns the close linking of a lookup engine which 
obtains associated data from an examination of the header of a packet and a separate post 
processor which acts either on the header or the associated data (depending on the 
processing function) to modify the associated data. In particular, the associated data 
includes a provisional port bit mask which in the absence of any other considerations 
would determine the port or ports from which the packet should be forwarded; the port 
mask would normally identify a single port for a 'unicast' packet but would identify a 
plurality of ports if the packet were a multicast or broadcast packet. The post-processor 
is intended to perform other processing, dependent on the user's requirements and 
otherwise. For example there may be a security function or a monitoring function. The 
former may require that the packet be sent to a different selection of ports than is 
specified in the unmodified bit mask. The latter may require that the packet be sent to a 
ports additional to the port or ports specified in the unmodified bit mask. 

An important advantage of the applicant's invention is that the additional or post- 
processing may be customized without requiring reprogramming of the main search 
engine. 

The rejection of claims 1,2,6,7 and the previous claim 1 1 are moot in view of the 
deletion of those claims. 
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The Examiner asserts that Muller (US-6 128666) shows a lookup engine and a 
network processor. Although Muller has a lookup engine (Figure 3, item 315) and a so- 
called 'input packet process' 310 and a 'logic unit 314', included, in the words of 
Muller (Col 6, lines 4 and 5) to 'forward control information and also replace 
predetermined fields of the header as the header is transmitted out of the input packet 
processor 310 and into the packet memory 325'. 

Muller fails to disclose any network processor which modifies the port bitmask. 
Such is not disclosed either in the cited passage or elsewhere. 

The presently presented claim limitations clearly define a network processor 
which acts to modify the (provisional) port bitmask. They clearly specify the signaling of 
such a network processor by the lookup engine and a return signal from the network 
processor on the completion of a function which modifies the port bitmask. The 
Examiner has already acknowledged that these features are not shown in either Muller or 
Epps. 

Epps is cited by the Examiner only to show a register for receiving a header 
portion of a packet. This is conceded, but obviously does not significantly alter the lack 
of foundation for the rejection as discussed above. 

The summary of Examiner's rejection of claims 3 and 8 is that: 
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Muller and Epps disclose a network switch with a database search engine 
fore information to modify packet header with associated destination data 
addresses using input registers. 

However, the examiner is reminded that the claims are not directed to 
modification of a packet header with associated destination data addresses using input 
registers. A port bitmask is not part of a packet header. It is not a destination address. It is 
an instruction to a switching engine, not part of a packet. The fundamental basis of the 
rejection is therefore unsound. 

The Examiner relies on Ambe to allegedly show a network processor 'which 
executes said processing function to cause modification of said port bitmask'. specifically 
in 'Figure 2, page 5 column 2 paragraphs [0096] -[0099] reference by the fast Filtering 
* processor'. 

The Examiner's assertion is without basis in Ambe. Paragraph 0096 of Ambe 
describes the sending and reception of an ARR (address resolution request) using a MAC 
address and VLAN ID. Paragraph 0097 describes the outcome of the ARR search as 
including an 'untagged port bitmap'. Paragraph 0098 refers to modification of the packet 
(not the bitmap) in terms of its 802. lq header or the TOS precedence field. These are 
parts of the packet, not the bitmap. Paragraph 0099 again refers to the modification of the 
packet in the buffer slicer. 
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The generation of the port bitmask (port bitmap) is actually described in Ambe 
paragraph [0234], and is performed by the search engine alone. The (final) port bitmask 
is obtained by the bitwise OR operation of an L2 bitmap and a L3 bitmap. 

In summary there is in no reference or any combination thereof any disclosure of a 
separate network processor which is linked to the lookup engine in the manner claimed or 
the modification by such a network processor of a port bitmask. 

Accordingly, this entire application is now believed to be in allowable condition 
and a formal Notice to that effect is respectfully solicited. 



LSN:vc 

901 North Glebe Road, 1 1th Floor 
Arlington, VA 22203-1808 
Telephone: (703) 816-4000 
Facsimile: (703) 816-4100 



Respectfully submitted, 



NIXON & VANDERHYE P.C. 
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